今回は2011年の災害を振り返って「リスク管理」を考えましょう。

　一応、リクスとは「不確実」と区別して、確率表記できるものであると定義し、リスク
管理を「予想された結果と、現実の結果の差」とします。
　つまり、『確率α％で起こり得る』と書けないものはリスクではなく、管理の対象には
なりません。　（ISO31000）

リスク管理の通常時にやることは次の項目です。　
　●リスクの想定／定量化→対策の計画（リスク評価）
　●リスクの低減・回避・有事の訓練（リスク対策）
　●点検・調査（リスクの監視）

　分かり易く、設計ミスをリクス管理手法で考えてみましょう。
設計者Aのミスの平均確率は○％、設計者Bのミスの確率は△％との定量化を行い（リス
ク抽出・評価）、技術研修・保有技術の評価、等の設計ミスの発生防止活動（リスク対策）、
設計活動の評価（リスクの監視）が日常活動でしょう。
　この様に、リスク管理と言っても特別ではなく、「抽出→評価→対策→監視」というサ
イクルを回す事は、ISO9000と変わりません。

　その上で、昨年の災害について考えましょう。数百年に1回の東日本地震
と数年に1回のタイの洪水です。同じような災害として扱われていますが、両者にはハッ
キリと発生確率に差があります。

　災害としては、東日本地震は避けられないものですが、タイの洪水は違います。海抜数
mの工業団地を選べば、間違いなく回避できた災害です。
　バンコクより北の稲作地域が水没しやすいのは私でも知っている現地の常識であり、TV
で見ると、現地の人も落ち着いたものです。
　場所選定ミスはいわば、人災と言えるものです。チェンマイの様子を見ていれば、一ヶ
月先に、どうなるか予測すらできたのです。

　ですからサプライチェーンの2重化すら忘れてタイの洪水被害を「想定外の天災」だと
主張するリスクマネージャーは「私は無能です」といっているに等しいのです。

　そして、今日考えなければならないのは、災害は地域限定のものだけではないというこ
とです。
　地震は当然の事ながら、太陽のフレア爆発による電子データの喪失や送電系統のダウン、
等の宇宙からの災害も想定し、生産拠点の複数化やデータのバックアップを取る必要があ
ります。そして、バックアップを取るということはメディアを替え、保存地域を変えると
いうことです。
・東京がダメなら大阪、
・電子データがダメなら紙データ、
等を考える必要があるということを忘れてはなりません。